REMARKS 

Applicants have carefully reviewed the arguments presented in the Office Action and 
respectfully request entry of the amendment and reconsideration of the claims in view of the 
remarks presented below. 

Claims 19-23 have been withdrawn. Thus, claims 1-18 are pending in the application. 

Claims 1-18 were rejected under 35 U.S.C. 102(b) as being anticipated by Tomkow 
(International Pub. No. WO 01/10090). Applicant respectfully traverses this rejection. 

It is axiomatic that, to anticipate a claim, a reference must disclose each and every 
element or step of the claim. Also axiomatic is that the claim must be read as a whole, that is, 
each claim element and limitation, as set forth in the claim, must be found in the cited reference. 
Applicant respectfully submits that this is not the case here. 

The Examiner has either misread Tomkow, the cited reference, Applicant's pending 
claims, or both. For example, to reject the claim term "adding a pixel to the message at the 
server, the pixel capable of being altered to indicate that the message has been opened by a 
recipient" the Examiner cites to page 13, line 19 to page 14, line 31 of Tomkow. The cited 
section is titled "MUA NOTICES (READING NOTIFICATIONS)" and describes the operation 
of a MUA. This section defines MUA notices as: 

[EJmails that are sent to the (nominal) author of a message by the 
recipient's Mail User Agent (MUA)(e-mail program) when certain 
events occur: e.g. the message is opened for reading, or deleted 
from the system without being read. By internet convention (RFC 
1891), no MUA program can be forced to generate such 
notifications. Whether an MUA will generate these receipts will 
depend upon the configuration chosen by its user , (emphasis 
added). 

Tomkow goes on to state: 

The RPost server 14 will configure and transmit messages in a way 
that attempts to elicit both MTA DSNs and MUA notices from 
compliant MTAs and MUAs. In order to elicit a Reading Receipt 
from compliant MUAs, certain headers must be included in the 
header section of an e-mail message. Different MUAs respond to 
different header; hence Server 14 will add several different headers 
to each message requesting a read notification in a form recognized 
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by various MUAs. These headers all take the form: Header label: 
user name <user address>. 

For example: Disposition-notification-to: john smith 
jsmith@adomain .com ; read-notification-tO: john smith 

> 3 "' cidomain.com 

Where john smith is the name of the user to whom an MUA 
notification is to be sent and ^jsmithfa.adomain.com' is that user's 
Internet address. Normally such headers would refer to the author 
of the message but in the case of the present method it is required 
that the notification be returned to RPost so that the notification 
can be processed by RPost. To assure that this is so Server 14 will 
insert headers that request that MUA receipts be sent to an address 
where then can be processed by the RPost server, for example, 
"readreceipt@RPost.com." This will direct any compliant 
recipient MUAs to send their notifications to an RPost address for 
processing, (emphasis added). 

It is clear from the above quoted text that Tomkow does not teach, or even suggest, 
adding, at a server, a pixel that is capable of being altered to indicate that the message has been 
opened to the message before the message is sent to a recipient, as is claimed in amended claim 
1. As recited by claim 1, the message, including the pixel, is then sent to the recipient, where, 
when the message is opened, the pixel is altered to indicate the opening of the message, and then 
the message and the altered pixel is transmitted back to the server for further processing before 
the message and altered pixel are sent to the sender of the message. 

In contrast, Tomkow (see above quoted text) only teaches adding a header to a message, 
where the header includes an instruction to a MUA to send a read notification back to a specified 
address. Tomkow's header does not change when the message is opened . Moreover, Tomkow's 
header will only elicit a response from a compliant MUA; if the MUA is not compliant with the 
header request, or has been instructed to ignore header requests, no response can be elicited. 

A further distinction is that a compliant MUA creates the email that it returns to the 
address indicated in the header. (See Tomkow, page 13, lines 20-25). This is not the same as is 
claimed in Applicant's claim 1 , where a pixel is added to the message at the server, and the pixel 
is altered when the message is opened, and the message with the altered pixel is sent back to the 
server. No new email is created when the pixel is altered. 
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According to claim 1, the mere opening of the message by the recipient causes the pixel 
to be altered and the message and altered pixel sent back to the server. The claimed invention 
causes the pixel to be altered and the message and altered pixel sent back to the server even if the 
recipient's MUA is not configured to provide a read receipt. Thus, the invention of claim 1 
ensures that an indication of whether the message has been opened by a recipient is provided to a 
sender even if the recipient's email client does not otherwise provide such an indication. 

Claim 7 was amended similarly to claim 1 to recite that the message contains an alterable 
pixel that is altered to indicate that the message has been opened when the message is opened by 
a recipient, and that the message and the indication that the message has been opened is 
transmitted back to the server for further processing before it is forwarded to the sender. As 
stated above, Tomkow neither teaches nor suggests transmitting a message with such an alterable 
pixel, nor altering the pixel to indicate that the message has been opened by the recipient when 
the message is opened. 

Claim 13 was also amended similarly to claims 1 and 7. As amended, claim 13 recites 
that a pixel capable of being altered to indicate that a message has been opened by a recipient is 
added to a message at a server before the message and alterable pixel are sent to the recipient. 
Amended claim 13 also recites altering the pixel when the message is opened by the recipient 
and transmitting eh message and altered pixel from the recipient to the server. As stated 
previously, Tomkow neither teaches nor suggests transmitting a message with such an alterable 
pixel, nor altering the pixel to indicate that the message has been opened by the recipient when 
the message is opened. 

Applicant also respectfully submits that amended claims 1, 7 and 13 are not obvious in 
view of Tomkow. Tomkow only discloses the use of emails created by a recipient's MUA as 
notifications that a message has been opened. Such messages are generated by the recipient's 
MUA, and do not include a copy of the original message. Tomkow teaches adding headers to a 
message to ensure that the MUA notifications are directed to an RPost server, where the MUA 
notification is matched to the original message. 

In contrast to the teachings of Tomkow, amended claims 1, 7 and 13 all teach sending a 
message having an alterable pixel to a recipient. When the recipient opens the message, the pixel 
is altered to indicate that the message has been opened, and then the message, and the altered 
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pixel, are sent back to the server. Thus, the indication that the message has been opened and the 
message do not need to be matched at the server when the indication that the message has been 
opened is received by the server, as must occur when using the system disclosed by Tomkow. 
This eliminates the possibility of mismatching the message and the indication that the message 
has been opened. Moreover, using the methods claimed in amended claims 1, 7, and 13, the 
server can provide the sender with an indication that the message has been opened even if the 
recipient's MUA is not configured to provide such notifications. Tomkow does not provide 
solutions to these problems, nor would the solution provided by the methods of the amended 
claims be ascertainable from Tomkow by one skilled in the art. 

For all of the reasons above, Applicant respectfully submits that amended claims 1, 7, 
and 13, and their dependent claims, are patentable over the cited art and respectfully request that 
the rejections be withdrawn and that claims 1-18 be allowed. 
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CONCLUSION 

Applicants have carefully reviewed the arguments presented in the Office Action and 
respectfully request reconsideration of the claims in view of the remarks presented. In light of 
the above amendments and remarks, Applicants respectfully request that a timely Notice of 
Allowance be issued in this case. 

Should the Examiner have any questions concerning the above amendments and 
arguments, or any suggestions for further amending the claims to obtain allowance, Applicants 
request that the Examiner contact Applicants' attorney, John Fitzgerald, at 310-242-2667. 

The Commissioner is authorized to credit any overpayment or charge any additional fees 
in this matter to our Deposit Account No. 06-2425. 
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